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DETAILED ACTION 

1. This action is responsive to the following* communication: Original application filed on 7 
October 2003. 

2. Claims 1-35 are pending and present for examination. Claims 1, 14, 20 and 23 are 
independent. 

Specification 

3. The disclosure is objected to because of the following informalities: " 

a. Specification, paragraph [0036], the following sentence is objected to: 

"In such cases, the article of manufacture in which the code is imptemented may 
comprise a transmission media, such as a network transmission line, wireless transmission 
media, signals propagating through space, radio waves, infrared signals, etc." 

While it is proper to say that a transmission medium transmits data (including program 
code), it is not proper nor correct to say that a transmission medium "implements" code by the 
activity of transporting the code. Unlike a conventional data recording media, such as an optical 
or magnetic disk, which implements stored code as tangible (i.e., physical, structural) changes to 
the media, in the above language, the transmission does not "implement" stored code while the 
code is being transmitted. 

Examiner's Note : For example, in the case of an optical medium storing code the "implementing" of 
the code means that certain regions of the optical disk material have been tangibly (physically, 
structurally) altered so that these regions reflect laser light differently when they have stored a 
"0" rather than a "1". And, in the optical disk, a particular region is tangibly changed by the 
implementation process, for example, a write consists of a laser "burn" of that region to make a 
tangible difference in the media. However, in the case of a wired (or wireless) network path 
over which so-called "implemented" code is being transmitted, there is no tangible (physical, 
structural) change to the transmission media, whether air, space, optical fiber, or copper wire. 

In the above language there is no equivalent process to the laser "burn" in relation to the 
transmission medium when a transmitted electromagnetic carrier wave transports embedded 
program code across a transmission path of a network. The transmission of program code across 
such a transmission medium is an entirely different process than the storage of program code in 
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a storage medium because the transmission media does not experience any tangible, structural 
change by the process of transmission (or the so-called "implementation"). 

See State Street, 149 F.3d at 1373, 47 USPQ2d at 1601-02. MPEP 2106. The claimed 
invention as a whole must accomplish a practical application. That is, it must produce a 'useful, 
concrete and tangible result " (emphasis added). 

In the above language, 

i. The claimed invention (program code being transported across a wireless 
medium) does not accomplish any useful, concrete and tangible result because 
the code does not tangibly, structurally alter the medium, and 

ii. The code has not functionality in the state of being transmitted because 
the embedded code cannot be executed as there does not exist any known 
processor able to execute the transmitted program code while in the process of 
being transmitted. Before the transmitted program code can be executed it must 
first be received and extracted from the transmission encoded carrier wave, and 
then stored on a suitable computer readable medium from which it can be 
executed by a processor as a functional part of a computer machine which 
includes the processor and the stored code. Until these steps are taken the 
transmitted program code has no program functionality, but instead, in the 
transmitted state the transmitted code can only represent, or is equivalent to, 
non-functional descriptive material. 

Therefore, the Specification erroneously asserts that program code being transmitted 
across a transmission medium somehow represents "implemented code." However, this is not 
true because the Specification does not teach details of how such an "implementation" makes 
any tangible (Physical, structural) alteration of the transmission media, or how the transmitted . 
code can be executed by a processor while in the state of being transmitted. The state of the , 
above language would require undue experimentation by one of ordinary skill in the art to read 
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Applicant's disclosure and then to accomplish tangible implementation of the transmitted 
program code or to accomplish execution of the transmitted program code. Furthermore, 
notwithstanding that the transmitted code clearly is contained in the transmission medium 
(because it is transported through the medium), "contained" and "implemented" do not carry the 
same meaning. 

Applicant's interpretation contradicts State Street, because first, when program code is 
being transmitted in any of the examples of transmission media listed above, no tangible 
(physical, structural) change has been made to the transmission media by the so-called 
"implementation" of the transmitted. Secondly, program code being transmitted cannot be 
executed by any known processor to perform any of the code's intended functionality, because in 
that state, the transmitted code remains nothing more than non-functional descriptive material. 

b. Specification, paragraph [0036], the following sentence is objected to: 

"Thus, the 'article of manufacture' may comprise the medium in which the code, is embodied/' 

Because this sentence, taken together with the previous sentence, further suggest that 
program code can be "embodied" in an intangible medium such as signals propagating through 
space, or that program code can be "embodied" in a tangible network path which merely carries 
encoded electromagnetic signals. However, for all the reasons noted above in paragraph (aO, 
and incorporated herein, these concepts do not reflect a permissible or correct interpretation of 
what kinds of media can "embody" program code under 35 U.S.C. § 101 in view of State Street 
since in neither case does such code tangibly (structurally, physically) alter the transmission 
media (whether air, space, or wire) nor can such code be executed by any process to attain the 
intended code's functionality while in the state of transmission. 

Appropriate correction is required. 

Claim Rejections -35 USC §112 
4. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shalf contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
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pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best 
mode contemplated by the inventor of carrying out his invention. 

5. Claims 23-35 are rejected under 35 U.S.C. § 101 because the claimed invention is not 
supported by either a specific and substantial asserted utility or a well-established utility. 

The claims are directed toward "an article of manufacture" which "causes operations to 
be performed." The claimed article of manufacture refers to code implemented in a computer 
readable medium which covers a transmission medium including: a network transmission line, 
wireless transmission media, signals propagating through space, radio waves, and infrared 
signals. See Specification, paragraph [0039]. These instances of transmission media are not 
supported by either a specific and substantial asserted utility or a well-established utility in 
association with any inherent properties of the code that is being transported because at no time - 
during the transmission of code is any code capable of being executed to cause any operations to 
be performed since no code is executed during transmission. Furthermore, any code in the state 
of being transmitted is merely the equivalent of transported data, that is, it is equivalent to non- 
descriptive material, since data in such a state cannot be executed to achieve any functionality of 
the code. Broadly speaking, no code being transmitted across a transmission media is ever 
executed during transmission to achieve the functionality of the transmitted code. The utility of a 
transmission line is only to accomplish the successful transmission of the embedded code, no 
matter what the code's purpose is. Otherwise, there cannot be any other utility for the 
combination of the transmission media and the code being transmitted, other than the 
accomplishment of the transported code, including any kind of inferred specific utility the 
embedded code may have when the code is properly stored on a suitable computer readable 
medium under 35 U.S.C. § 101 and then executed by a processor. In summary, the transmission 
media carrying embedded program code does not interact with any kind of known transmission 
processor having the ability to execute the embedded transmitted code. Therefore, there is no 
actual utility for the transmitted code while in the state of being transmitted other than the utility 
of the non-functional descriptive material being successfully transmitted. The transmitted code 
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therefore cannot be used to accomplish the claimed "operations to be performed" while being . 
transmitted. 

6. Claims 23-35 are also rejected under 35 U.S.C. 112, first paragraph. Specifically, since 
the claimed invention is not supported by either a specific and substantial asserted utility or a 
well established utility for the reasons set forth above, one skilled in the art clearly would not 
know how to use the claimed invention. 

Claim Rejections ~ 35 USC § 101 

7. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

8. Claims 23-35 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. The claims are directed toward "an article of 
manufacture" which "causes operations to be performed," and are non-statutory because they 
encompass subject matter and/or embodiments which do not fall within a statutory category. 

The meaning of "article of manufacture" as disclose in the Specification, paragraph 
[0039], covers non-statutory embodiments which improperly include network transmission lines 
(interpreted as wired and wireless transmission), wireless transmission media, signals 
propagating through space, radio waves, infrared signals, etc. For the aforementioned reasons 
discussed in the objections to the Specification, paragraphs [0039], which are incorporated 
herein, the claimed invention does not properly cover only statutory subject matter (e.g., 
program code being transmitted over wired or wireless transmission media) because in such a 
case there is no tangible embodiment of program code in a computer readable medium executed 
by a processor, and further because the disclose program code being transmitted across the 
transmission media cannot be executed by any known processor. Therefore, the transmitted 
program code lacks functional capability because, absent execution, it cannot cause any of the 
claimed operations to be performed, and so, in the state of being transmitted, the program code 
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represents nothing more than non -functional descriptive material. Moreover, under 35 U.S.C. § 
101, signals propagating through space, radio waves, and infrared signals are not permissible 
"articles of manufacture" because they have no tangible embodiment. 



Claim Rejections - 35 USC§ 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject matter 
sought to be patented and the prior art are such that the subject matter as a whole would 
have been obvious at the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains. Patentability shall not be negatived by the manner 
in which the invention was made. 

10. Claim 1, 2, 10-11, 13-15, 18, 20-21, 23-24, 32-33, and 35 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Crouse et al (U.S. Patent No. 5,764,972, hereinafter 
referred to as CROUSE), filed on 7 June 1995, and issued on 9 June 1998, in view of Hug et al 
(U.S. Patent No. 5,806,078, hereinafter referred to as HUG), filed on 9 June 1994, and issued on 
8 September 1998, and Gonos (U.S. Patent No. 6,901,418, hereinafter referred to as GONOS), 
filed on 7 May 2002, and issued on 31 May 2005. 

CROUSE, HUG, and GONOS teach the limitations of claims 1, 2, 10-11, 13-15, 18, 20-21, 
23-24, 32-33, and 35 for the reasons stated below. 

11. As per independent claims 1 and 23, CROUSE, in combination with HUG and 
GONOS, discloses: 

A method, comprising: 



processing a request to write to a source file in a storage system {See 

GONOS, col. 5, lines 37-40, wherein this reads over "a process controls a processor to archive data 
and the structure used for the archived data. The process is initiated when a determination is made 
that a particular dataset is going to be archived"}; 

determining whether a retention rule is provided for the source file {See 

CROUSE, col. 20, lines 40-64, wherein this reads over "the RM module examines the direct access 
parameter of the file migration attributes to determine if direct access to the remote file is allowed"; 
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and col. 21, lines 43-46, wherein this reads over u [i]f all selection criteria specified in the selection 
attributes are met by the file attributes and the file access information, that that remote file is eligible 
for archiving and/or removal"}! 

in response to determining that one retention rule is provided for the 
source file, generating a versioned file name, wherein a versioned file comprises 

the source file at a point-in-time {See HUG, col. 6, lines 28-41, wherein this reads over 
"identification data preferably identifies the date and time the version was created, a version name 
associated with the version"}^ 

transmitting a command to a file system to copy the source file data to a 

versioned file (See GONOS, col. 6, lines 25-34, wherein this reads over "processor copies to the 
archive file the rows that meet the archiving criteria"} having the generated versioned file 
name {See CROUSE, col. 21, lines 3-16, wherein this reads over "making an archival copy of that 
file ... up to four different copies of a backup/archive image of a remove file can be created"}; 

adding the generated versioned file name to a retention index file {See 

GONOS, col. 6, lines 43-50, wherein this reads over "[t]he archive index file and the archive index 
identification file describe the data stored in the archive file for the data set"} ; and 

processing the retention Index file to determine whether to purge 
versioned files according to the retention rule provided for the source file {See 

CROUSE, col. 21, lines 24-28, wherein this reads over "the AR module automatically begins to purge 
or archive remote files that are eligible for elimination or archiving in accordance with their 
hierarchically selectable archival file attributes"^ 

The combination of inventions disclosed in CROUSE, HUG, and GONOS would disclose a 
method comprising of processing a request to write to a source file in a storage system (i.e. a 
process that controls a processor to archive data"), determining whether a retention rule is 
provided (i.e. through a selection criteria of file attributes), generating a version name (i.e. 
creating a version name associated with the version), transmitting a command to copy the source 
file data to a version filed (i.e. copying rows that meet the archive criteria to an archive file), 
adding the versioned file name to a retention index file (i.e. the archive index file describe the 
data stored in the archive file), and processing the index file to determine whether to purge the 
version files (i.e. accessing the index file to see whether or not the archive files are eligible for 
elimination or archiving). Therefore, it would have been obvious to one of ordinary skill in the art 
at the time the invention was made to combine the inventions suggested by CROUSE, HUG, and 
GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
copies of different versions of a file may be maintained. 
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12. As per dependent claims 2, 15, 21, and 24, CROUSE, in combination with HUG and 
GONOS, discloses: 

The method of claim 1, wherein purging the versioned files comprises: 

determining versioned files to purge according to the retention rule {See 

CROUSE, col. 21, lines 24-28, wherein this reads over "the AR module automatically beings to purge 
or archive remote files that are eligible for elimination or archiving in accordance with their 
hierarchically selectable archival file attributes"}; 

deleting the determined versioned file names from the retention index 
file {See GONOS, col. 7, lines 60-67, wherein this reads over "when processing of 

each database table. in the dataset is complete (step 580), the processor may delete unnecessary 
archive information (step 590). For example, the processor may delete the archive file, the archive 
index file, and the archive index identification file after a predetermined period of time has passed 
since those files were created or a predetermined period of time has passed since those file were 

used."> : and 

transmitting a command to the file system to delete versioned files 
having the determined versioned file names {See crouse, col. 21, lines 24-28, wherein 

this reads over "the AR module automatically begins to purge or archive remote files that are eligible 
for elimination"^ 

The combination of inventions disclosed in CROUSE, HUG, and GONOS would disclose a 
method wherein purging the versioned file comprises of determining which versioned files to 
purge (i.e. determining which files are eligible for elimination or archiving), deleting the versioned 
file names from the retention index file (i.e. the processor may delete unnecessary archive 
information), and transmitting a command to delete the versioned files (i.e. the AR module 
automatically beings to purge or archive remote files that are eligible for elimination). Therefore, 
it would have been obvious to one of ordinary skill in the art at the time the invention was made 
to combine the inventions suggested by CROUSE, HUG, and GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
purge-eligible versioned files may be deleted from the system and the versioned filed names may 
be removed from the index file. 

13. As per dependent claims 10, 18 and 32, CROUSE, in combination with HUG and 
GONOS, discloses: 

The method of claim 1, 



wherein the operations of 
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prOCeSSinQ the request (See CROUSE, col. 20, lines 40-64, wherein this 
reads over "in response to a request to read a remove file that is presently stored on a 
removable media"}* 



determining whether one retention rule is provided (See crouse, 

col. 20, lines 40-64, wherein this reads over "the RM module examines the direct access 
parameter of the file migration attributes to determine if direct access to the remote file is 
allowed"; and col. 21, lines 43-46, wherein this reads over "[i]f all selection criteria 
specified in the selection attributes are met by the file attributes and the file access 
information, that that remote file is eligible for archiving and/or removal"} A 



generating a new versioned file name (See hug, col 6, lines 28-41, 

wherein this reads over "identification data preferably identifies the date and time the 
version was created, a version name associated with the version"} x 

transmitting the command (See CROUSE, col. 21, lines 3- 16, wherein this 
reads over "making an archival copy of that file ... up to four different copies of a 
backup/archive image of a remove file can be created"} x 

adding the generated versioned file name to the retention index 

file (See GONOS, col. 6, lines 43-50, wherein this reads over "[t]he archive index file and 
the archive index identification file describe the data stored in the archive file for the data 

sen and 

processing the retention index file are performed by a host 

System (See CROUSE, col. 21, lines 24-28, wherein this reads over "the AR module 
automatically begins to purge or archive remote files that are eligible for elimination or 
archiving in accordance with their hierarchically selectable archival file attributes "}and 

wherein the versioned file, source file, and file system are on a remote 

Storage System (See CROUSE, col. 7, line 65 - col. 8, line 2, wherein this reads over "the remote 
files stored on the remote secondary storage system and the local files stored on the local secondary 
storage system are stored and accessed in accordance with a file system tree structure"}^ 

The combination of inventions disclosed in CROUSE, HUG, and GONOS would disclose a 
method comprising of processing a request to write to a source file in a storage system (i.e. a 
process that controls a processor to archive data"), determining whether a retention rule is 
provided (i.e. through a selection criteria of file attributes), generating a version name (i.e. 
creating a version name associated with the version), transmitting a command to copy the source 
file data to a version filed (i.e. copying rows that meet the archive criteria to an archive file), 
adding the versioned file name to a retention index file (i.e. the archive index file describe the 
data stored in the archive file), and processing the index file to determine whether to purge the 
version files (i.e. accessing the index file to see whether or not the archive files are eligible for 
elimination or archiving). Therefore, it would have been obvious to one of ordinary skill in the art 



Application/Control Number: 10/680,953 Page 
Art Unit: 2161 

at the time the invention was made to combine the inventions suggested by CROUSE, HUG, and 
GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
copies of different versions of a file may be maintained. 

14. As per dependent claims 11 and 33, CROUSE, in combination with HUG and GONOS, 
discloses: 

The method of 10, wherein retention index files are maintained at local storage 
to the host system and accessed locally by the host system to determine versioned files 

to puroe according to retention rules {See CROUSE, col. 7, line 65 - col. 8, line 2, wherein this reads 
over "the remote files stored on the remote secondary storage system and the local files stored on the local 
secondary storage system are stored and accessed in accordance with a file system tree structure"}. 

The combination of inventions disclosed in CROUSE, HUG, and GONOS .would disclose a 
method wherein retention index files are maintained at local storage to the host system and 
accessed locally by the host system. Therefore, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to combine the inventions suggested by 
CROUSE, HUG, and GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
the retention index files may be readily accessible to the host system for determining which , 
versioned filed to purge according to the retention rules. 

15. As per dependent claims 13 and 35, CROUSE, in combination with HUG and GONOS, 
discloses: 

The method of claim 1. wherein the retention rule identifies a name of one 
source file to which the rule applies or identifies a source that created the source file to 

which the rule applies (See CROUSE, col. 20, lines 40-64, wherein this reads over "the RM. module 
examines the direct access parameter of the file migration attributes to determine if direct access to the remote 
file is allowed"; and col. 21, lines 43-46, wherein this reads over "[i]f all selection criteria specified in the 
selection attributes are met by the file attributes and the file access information, that that remote file is eligible 
for archiving and/or removal "}± 

The combination of inventions disclosed in CROUSE, HUG, and GONOS would disclose a 
method wherein the retention rule identifies a name of a source file or source to which the rule 
applies (i.e. application of the selection criteria to the files in order to determine which are eligible 
for archiving and/or removal). Therefore, it would have been obvious to one of ordinary skill in 
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the art at the time the invention was made to combine the inventions suggested by CROUSE, 
HUG, and GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
the rules may be properly assigned and applied to certain source files. 
16. As per independent claims 14 and 20, CROUSE, in combination with HUG and 
GONOS, discloses: 

A system, comprising: 

a first storage system including source files {See crouse, col. 7, line 65 - col. 

8, line 2, wherein this reads over "the remote files stored on the remote secondary storage system 
and the local files stored on the local secondary storage system are stored and accessed in 
accordance with a file system tree structure"} ! 

a second storage system including retention rules for the source files (See 

CROUSE, Figure 9; and col. 17, lines 56-67, wherein this reads over "four program modules that are 
called . . . the removable media manager (RM) module, and the archiving (AR) module, the file 
system (FS) module"}! 

a file system (See CROUSE, col. 4, lines 22-25, wherein this reads over "an archiving 
- file system"}! 

means for processing a reguest to write to one of the source files in the 

first Storage System (See CROUSE, col. 20, lines 40-64, wherein this reads over "in response to 
a request to read a remove file that is presently stored on a removable media"}! 

means for determining whether one of the retention rules is provided for 

the Source file (See CROUSE, col. 20, lines 40-64, wherein this reads over "the RM module 
examines the direct access parameter of the file migration attributes to determine if direct access to 
the remote file is allowed"; and col. 21, lines 43-46, wherein this reads over "[i]f all selection criteria 
specified in the selection attributes are met by the file attributes and the file access information, that 
that remote file is eligible for archiving and/or removal"}! 

means for generating a versioned file name in response to determining 
that one retention rule is provided for the source file, wherein a versioned file 
comprises the source file at a point-in-time (See hug, col. 6, lines 28-41, wherein this 

reads over "identification data preferably identifies the date and time the version was created, a 
version name associated with the version"}! 

transmitting a command to the file system to copy the source file data to 
a versioned file having the generated versioned file name in the first storage 

System (See CROUSE, col. 21, lines 3-16, wherein this reads over "making an archival copy of that 
file ... up to four different copies of a backup/archive image of a remove file can be created"}! 

means for adding the generated versioned file name to a retention index 

file in the Second Storage SVStem (See GONOS, col. 6, lines 43-50, wherein this reads over 
"[t]he archive index file and the archive index identification file describe the data stored in the 
archive file for the data set" }: and 
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means for processing the retention index file to determine whether to 
purge versioned files according to the retention rule provided for the source file 

{See CROUSE, col. 21, lines 24-28, wherein this reads over "the AR module automatically begins to 
purge or archive remote files that are eligible for elimination or archiving in accordance with their 
hierarchically selectable archival file attributes"^ 

The combination of inventions disclosed in CROUSE, HUG, and GONOS would disclose a 
method comprising of processing a request to write to a source file in a storage system (i.e. a 
process that controls a processor to archive data"), determining whether a retention rule is 
provided (i.e. through a selection criteria of file attributes), generating a version name (i.e. 
creating a version name associated with the version), transmitting a command to copy the source 
file data to a version filed (i.e. copying rows that meet the archive criteria to an archive file), 
adding the versioned file name to a retention index file (i.e. the archive index file describe the 
data stored in the archive file), and processing the index file to determine whether to purge the 
version files (i.e. accessing the index file to see whether or not the archive files are eligible for 
elimination or archiving). Therefore, it would have been obvious to one of ordinary skill in the art 
at the time the invention was made to combine the inventions suggested by CROUSE, HUG, and 
GONOS. 

One of ordinary skill in the art would have been motivated to do this modification so that 
copies of different versions of a file may be maintained. 

17. Claims 3-4, 16, 22, and 25-26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over CROUSE, in view of HUG and GONOS, and in further view of Howard (U.S. 
Patent No. 6,098,079, hereinafter referred to as HOWARD, filed on 2 April 1998, and issued on 1 
August 2000. 

CROUSE, HUG, and GONOS teach the limitations of claims 1, 2, 10-11, 13-15, 18, 20-21, 
23-24, 32-33, AND 35 for the reasons stated above. 

CROUSE, HUG, and GONOS differ from the claimed invention in that they fail to disclose, 
a method wherein the generated versioned file name is added to the retention index (claims 3„ 
16, 22, and 25). 
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CROUSE, HUG, and GONOS differ from the claimed invention in that they fail to disclose 
a method wherein the function comprises a hash function (claims 4 and 26). 

18. \ As per dependent claims 3, 16, 22, and 25, CROUSE, in combination with HUG, 
GONOS, and HOWARD, discloses: 

The method o f claim l f further comprising: 

applying a function to the source file name to determine the retention index file 

{See GONOS, col. 6, lines 45-46, wherein this reads over 4, [a]n archive index file and an archive index 
identification file are associated with each archive file"} x 

wherein the determined retention index file maintains names of 
versioned files for the source file to which the function is applied isee howard, col. 

2, lines 48-52, wherein this reads over M [t]he reconciliation technique uses a set of journal files in 
which the history of file creation, modification, and deletion throughout the system is recorded"},. 

and 

wherein the generated versioned file name is added to the 

determined retention index {See HOWARD, col. 2, lines 48-52, wherein this reads 
over "[t]he reconciliation technique uses a set of journal files in which the history of file 
creation, modification, and deletion throughout the system is recorded"}. 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and HOWARD would 
disclose a method wherein a function is applied to the source file to determine the retention 
index file (i.e. the index file is associated with each archive file), and wherein the retention index 
file maintains the versioned files (i.e. a set of journal files which record the history of creation, 
modification, and deletion of files). Therefore, it would have been obvious to one of ordinary skill 
in the art at the time the invention was made to combine the inventions suggested by CROUSE, 
HUG, GONOS, and HOWARD. 

One of ordinary skill in the art would have been motivated to do this modification so that 
the versioned file names may be added to the retention index. 

19. As per dependent claims 4 and 26, CROUSE, in combination with HUG, GONOS, and L 
HOWARD, discloses: 

The method of claim 3 f 

wherein the function comprises a hash function {See howard, col. 3, lines 

31-40, wherein this reads over "[e]ach version entry contains a hash code . . . [that] uniquely 
identifies the contents of a corresponding version of the file"> , and 
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wherein one retention index may maintain versioned file names for 
multiple source files to which the function is applied {See howard, col. 2, lines 48-52, 

wherein this reads over "[t]he reconciliation technique uses a set of journal files in which the history 
of file creation, modification, and deletion throughout the system is recorded"}.. 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and HOWARD would 
disclose a method wherein the function comprises a hash function and the retention index may 
maintain versioned file names for multiple source files. Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to combine the inventions 
suggested by CROUSE, HUG, GONOS, and HOWARD. 

One of ordinary skill in the art would have been motivated to do this modification in 
order to create a unique retention index file name, allowing for one retention index file to 
maintain information on versioned file names for different source files. - 

20. Claims 5-9, 17, and 27-31 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over CROUSE, in view of HUG and GONOS, and in further view of Kaler et al (U.S. Patent No. 
6,928,447, hereinafter referred to as KALER), filed on 21 May 2004, and issued on 9 August 
2005. 

CROUSE, HUG, and GONOS teach the limitations of claims 1, 2, 10-11, 13-15, 18, 20-21, 
23-24, 32-33, AND 35 for the reasons stated above. 

CROUSE, HUG, and GONOS differ from the claimed invention in that they fail to disclose 
a method wherein the versioned file names for the source file are ordered on a timestamp 
(claims 5, 17, and 27). 

21. As per dependent claims 5, 17, and 27, CROUSE, in combination with HUG, GONOS, 
and KALER, discloses: 

The method of claim 1, wherein processing the retention index file to 
determine whether to purge versioned files according to the retention rule 
further comprises: 

sorting the versioned file names for the source file in the 
retention, index file ordered on a timestamp included in the versioned file 
names {See KALER, Figure 23) : and 
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selecting versioned files from the sorted versioned file names to 

purge (See GROUSE, col. 21, lines 43-46, wherein this reads over tt [i]f all selection criteria 
specified in the selection attributes are met by the file attributes and the file access 
information then that remote file is eligible for archiving and/or removal"}. 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would 
disclose a method wherein the versioned file names are sorted according to their timestamps, 
and accordingly selected for purge (i.e. purged on the basis of the recorded timestamp). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the inventions suggested by CROUSE, HUG, GONOS, and KALER. 

One of ordinary skill in the art would have been motivated to do this modification so that 
the versioned files may be deleted according to the sort order. 

22. As per dependent claims 6 and 28, CROUSE, in combination with HUG, GONOS, and 
KALER, discloses: 

The method of claim 5, wherein the retention rule specifies a maximum 
number of versioned files to have for the source file {See crouse, coi. is, lines 19-49, 

wherein this reads over "[u]p to four copies of archival media may be specified for each remote file. 
Whether a remote file will be archived, how many copies will exist ... is determined by the following 

parameters in the file migration attribute" !, and wherein selecting versioned files to purge 
comprises: 

determining whether a number of the sorted versioned file 
names exceeds the maximum number (See crouse, col. is, lines M6, wherein 

this reads over u [w]hen a new version of a file is created the previous version will be saved 
as a cycle if cycles are enabled for that file. The user may specify the number of cycles to 
be maintained and their life space by setting the following attributes" and "Cycle Limit"}; 
and 

selecting a number of oldest sorted versioned file names to 
puroe to reduce the number of versioned file names in the retention 
index file to reach the maximum number (See crouse, col. 21, lines 28-30, 

wherein this reads over "[t]he remote files that are eligible for removal or archiving and 
have waited longest since last access will be eliminated or archived first"; and GONOS, col. 
7, lines 60-67, wherein this reads over "the processor may delete the archive file, the 
archive index file, and the archive index identification file after a predetermined period of 
time has passed since those files were created or a predetermined period of time has 
passed"}. 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would 
disclose a method wherein the retention rule specifies a maximum number of versioned files to 
have for the source file (i.e. how many copies of a source file may exist), and selecting the 
versioned files to purge comprises of determining whether the number of version file names 



i 
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exceeds a maximum number (i.e. cycle limit), and selecting the oldest versioned file names for 
purge (i.e. archiving or removing those files which have waited longest since last access or after 
a predetermined period of time has passed). Therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to combine the inventions suggested 
by CROUSE, HUG, GONOS, and KALER. 

One of ordinary skill in the art would have been motivated to do this modification so that 
older versioned files are systematically and routinely purged from the system. 
23. As per dependent claims 7 and 29, CROUSE, in combination with HUG, GONOS, and 
KALER, discloses: 

The method of claim 5, wherein the retention rule specifies a time limit 
on versioned files to maintain for the source file, and wherein selecting versioned 
files to purge comprises: 

determining whether sorted version file names exceed the time 
limit according to the timestamp for the sorted versioned file names {See 

CROUSE, col. 15, lines 1-16, wherein this reads over "[w]hen a new version of a file is' 
created the previous version will be saved as a cycle if cycles are enabled for that file. The 
user may specify the number of cycles.to be maintained and their life space by setting the 
following attributes" and "Cycle Life Span"} ; and 

selecting versioned file names in the retention index whose 
timestamp exceeds the time limit to purge versioned files whose 

timestamp exceeds the time limit {See CROUSE, col. 21, lines 28-30, wherein this 
reads over "[t]he remote files that are eligible for removal or archiving and have waited 
longest since last access will be eliminated or archived first"}^ 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would 
disclose a method wherein the retention rule specifies a time limit on versioned files to be 
maintained for the source file (i.e. how long a versioned file of a source file may exist), and 
selecting the versioned files to purge comprises of determining whether the number of version 
file names exceeds a time limit (i.e. cycle life span), and selecting the versioned file names which 
exceed the time limit for purge (i.e. archiving or removing those files which have waited longest 
since last access or after a predetermined period of time has passed). Therefore, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine 
the inventions suggested by CROUSE, HUG, GONOS, and KALER. 
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One of ordinary skill in the art would have been motivated to do this modification so that 
older versioned files are systematically and routinely purged from the system. 
24. As per dependent claims 8 and 30, CROUSE, in combination with HUG, GONOS, and 
KALER, discloses: 

The method of claim 5, wherein the retention rule specifies a time period 
and maximum number of versioned files to maintain for the source file within the 
specified time period, and wherein selecting versioned files to purge comprises: 

determining whether a number of the sorted versioned file 
names within the specified time period exceeds the specified maximum 

number (See CROUSE, col. 15, lines 1-16, wherein this reads over M [w]hen a new version 
of a file is created the previous version will be saved as a cycle if cycles are enabled for 
that file. The user may specify the number of cycles to be maintained and their life space 
by setting the following attributes", "Cycle Limit", and "Cycle Life Span"} ; and 

selectino a number of oldest sorted versioned file names to 
purge to reduce the number of versioned file names in the retention 
index file in the specified time period to reach the maximum number (See 

CROUSE, col. 21, lines 28-30, wherein this reads over n [t]he remote files that are eligible 
for removal or archiving and have waited longest since last access will be eliminated or 
archived first"}^ 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would 
disclose a method wherein the retention rule specifies a time limit on versioned files to be 
maintained for the source file (i.e. how long a versioned file of a source file may exist), and 
selecting the versioned files to purge comprises of determining whether the number of version 
file names exceeds a time limit (i.e. cycle life span), and selecting the versioned file names which 
exceed the time limit for purge (i.e. archiving or removing those files which have waited longest 
since last access or after a predetermined period of time has passed). Furthermore, the 
combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would disclose a 
method wherein the retention rule specifies a maximum number of versioned files to have for the 
source file (i.e. how many copies of a source file may exist), and selecting the versioned files to 
purge comprises of determining whether the number of version file names exceeds a maximum 
number (i.e. cycle limit), and selecting the oldest versioned file names for purge (i.e. archiving or 
removing those files which have waited longest since last access or after a predetermined period 
of time has passed). Therefore, it would have been obvious to one of ordinary skill in the art at 
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the time the invention was made to combine the inventions suggested by CROUSE, HUG, 
GONOS, and KALER. 

One of ordinary skill in the art would have been motivated to do this modification so that 
older versioned files are systematically and routinely purged from the system. 
25. As per dependent claims 9 and 31, CROUSE, in combination with HUG, GONOS, and 
KALER, discloses: 

The method of claim 8, . 

wherein the retention rule specifies multiple time periods and one 
maximum number for each time period to separately maintain versioned files for 
the source file for different time periods {See crouse, col. is, lines 1-16, wherein this 

reads over "[w]hen a new version of a file is created the previous version will be saved as a cycle if 
cycles are enabled for that file. The user may specify the number of cycles to be maintained and 
their life space by setting the following attributes" "Cycle Limit", and "Cycle Life Span"}, 

wherein the determining whether the number of versioned files to 
maintain for the source file excee ds the specified maximum number is performed 

for each Spec ified time period {See CROUSE, col. IS, lines 1-16, wherein this reads over 
"[w]hen a new version of a file is created the previous version will be saved as a cycle if cycles are 
enabled for that file. The user may specify the number of cycles to be maintained and their life 
space by setting the following attributes", "Cycle Limit", and "Cycle Life Span") , and 

wherein selecting the number of oldest versioned file names to purge to 
reduce the number of versioned file names in the retention index file is 
performed for each specified time period to reach the maximum number 

Specified for the time Period ISee CROUSE, col. 21, lines 28-30, wherein this reads over "[t]he 
remote files that are eligible for removal or archiving and have waited longest since last access will 
be eliminated or archived first"}.. 

The combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would 
disclose a method wherein the retention rule specifies a time limit on versioned files to be 
maintained for the source file (i.e. how long a versioned file of a source file may exist), and 
selecting the versioned files to purge comprises of determining whether the number of version 
file names exceeds a time limit (i.e. cycle life span), and selecting the versioned file names which 
exceed the time limit for purge (i.e. archiving or removing those files which have waited longest 
since last access or after a predetermined period of time has passed). Furthermore, the 
combination of inventions disclosed in CROUSE, HUG, GONOS, and KALER would disclose a 
method wherein the retention rule specifies a maximum number of versioned files to have for the 
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source file (i.e. how many copies of a source file may exist), and selecting the versioned files to 
purge comprises of determining whether the number of version file names exceeds a maximum 
number (i.e. cycle limit), and selecting the oldest versioned file names for purge (i.e. archiving or 
removing those files which have waited longest since last access or after a predetermined period 
of time has passed). Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the inventions suggested by CROUSE, HUG, 
GONOS, and KALER. 

One of ordinary skill in the art would have been motivated to do this modification so that 
older versioned files are systematically and routinely purged from the system. 

26. Claims 12, 19 and 34 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
CROUSE, in view of HUG and GONOS, and in further view of Official Notice. 

CROUSE, HUG, and GONOS teach the limitations of claims 1, 2, 10-11, 13-15, 18, 20-21, 
23-24, 32-33, AND 35 for the reasons stated above. 

CROUSE, HUG, and GONOS differ from the claimed invention in that they fail to disclose 
a method wherein a program executing in a kernel of an operating system (claims 12, 19, and 
34), . 

27. . As per dependent claims 12, 19, and 34, the claims are rejected under 35 U.S.C. 
103(a) as being obvious in view of CROUSE, HUG, GONOS, and in further view of Official Notice. 
It would have been obvious to one of ordinary skill in the art to have a program executed in a 
kernel of an operating system. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Paul Kim whose telephone number is (571) 272 2737. The examiner can 
normally be reached on M-F, 9am - 5pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Safet Metjahic can be reached on (571)272-4023. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR system, 
see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Paul Kim 

Patent Examiner, Art Unit 2161 
Technology Center 2100 
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